Revision control systems provide functionality for storing and managing versions of electronic documents. In order to provide this functionality, revision control systems typically maintain one or more document repositories. These repositories store electronic documents along with data that describes changes made to the documents by users of the revision control system.
Users of revision control systems may submit requests to make revisions to a document to document repositories at unpredictable intervals. When a revision request is received, a repository might be in an active state in which it is ready to receive revision requests, or in an offline state in which the repository cannot accept revision requests. Repositories in the active state consume computing resources continuously while repositories in the offline state do not. Repositories in the offline state must be restored to the active state before they can receive revision requests.
The usage of resources by active repositories might impose a scalability limitation on some revision control systems. For example, the consumption of resources by active repositories might prevent a revision control system from scaling to manage a large number of repositories. Repositories may be placed into an offline state in order to free the associated resources. However, restoring repositories to the active state can be a time-consuming operation. Users submitting revision requests to a revision control system may be frustrated by the time required to restore a document repository to the active state.
Some previous revision control systems provide functionality for allowing a user to commit changes to a repository that is in the offline state. These previous systems have typically relied on accessing a copy of the repository, determining that the commit can be made to the copy of the repository, updating the copy of the repository and, at a much later time (such as hours, days, or even weeks), attempting to merge the copy of the repository with the original repository. This approach, however, has several drawbacks. First, maintaining a copy of the repository may require considerable computing resources and may also limit scalability for hosting many repositories. Second, the act of merging two repositories may require labor-intensive, manual reconciliation work depending on how greatly the copy of the repository has diverged from the original repository.
It is with respect to these and other considerations that the disclosure made herein is presented.